A window manager is system software that controls the placement and appearance of windows within a windowing system in a graphical user interface.[1] Most window managers are designed to help provide a desktop environment. They work in conjunction with the underlying graphical system which provides required functionality such as support for graphics hardware, pointing devices, and a keyboard, and are often written and created using a widget toolkit.[2]
Few window managers are designed with a clear distinction between the windowing system and the window manager. Every graphical user interface which uses a windows metaphor has some form of window management; however, in practice, the elements of this functionality vary greatly.[3] The elements usually associated with window managers are those which allow the user to open, close, minimize, maximize, move, resize, and keep track of running windows, including window decorators. Many window managers also come with various utilities and features: e.g. docks, task bars, program launchers, desktop icons, and wallpaper.
Contents |
On systems using the X window system, there is a clear distinction between the window manager and the windowing system. Strictly speaking, an X window manager does not directly interact with video hardware, mice, or keyboards – that is the responsibility of the X server.
Users of the X Window System have the ability to easily use many different window managers – Metacity, used in GNOME, and KWin, used in KDE Workspace, and many others. Since many window managers are modular, people can use others, such as Compiz (a 3D compositing window manager), which replaces the window manager. Sawfish and awesome on the other hand are extensible window managers offering exacting window control. Components of different window managers can even be mixed and matched; for example, the window decorations from KDE Workspace's KWin can be used with the desktop and dock components of GNOME.
X window managers also have the ability to re-parent applications, meaning that, while initially all applications are adopted by the root window (essentially the whole screen), an application started within the root window can be adopted by (i.e. put inside of) another window. Window managers under the X window system adopt applications from the root window and re-parent them to window decorations (for example, adding a title bar). Re-parenting can also be used to allow the contents of one window to be added to another; for example, a flash player application can be re-parented to a browser window, and can appear to the user as supposedly being part of that program. Re-parenting window managers can therefore arrange one or more programs into the same window, and can easily combine tiling and stacking in various ways.
Microsoft Windows has provided an integrated stacking window manager since Windows 2.0; Windows Vista introduced the compositing dwm.exe as an optional hardware-accelerated alternative. In Windows, the role of the window manager is tightly coupled with the kernel's graphical subsystems and is largely non-replaceable, although third-party utilities can be used to simulate a Tiling window manager on top of such systems.
Windows Explorer (explorer.exe) is used by default in modern Windows systems to provide a panel and file manager, along with many functions of a window manager; aspects of Windows can be modified through the provided configuration utilities, modifying the Windows registry or with 3rd party tools, such as WindowBlinds or resource editors.
The Windows window manager can also act as an X window manager through Cygwin/X in multiwindow mode (and, possibly, other X window implementations).
Note that Microsoft and X Window System use different terms to describe similar concepts. For example, there is no specific word for window manager functionality in Windows (shell is sometimes used in this context, but its sense is fuzzy); probably, lacking such a term, Microsoft avoids advertising of third-party window managers.
Window managers are often divided into three classes, which describe how windows are drawn and updated.
Compositing window managers allow all windows to be created and drawn separately and then put together and displayed in various 2D and 3D environments. The most advanced compositing window managers allow for a great deal of variety in interface look and feel, and for the presence of advanced 2D and 3D visual effects.
All window managers that have overlapping windows and are not compositing window managers are stacking window managers, although it is possible that not all use the same methodologies. Stacking window managers allow windows to overlap by drawing background windows first, which is referred to as painter's algorithm. Changes sometimes require all windows to be re-stacked or repainted, which usually involves redrawing every window. However, to bring a background window to the front usually only requires that one window to be redrawn, since background windows may have bits of other windows painted over them, effectively erasing the areas that are covered.
Tiling window managers paint all windows on-screen by placing them side by side or above and below each other, so that no window ever covers another. Microsoft Windows 1.0 used tiling, and a variety of tiling window managers for X are available.
Dynamic window managers can dynamically switch between tiling or floating window layout. A variety of dynamic window managers for X are available.
In the 1970s, the Xerox Alto became the first computer shipped with a working WIMP GUI. It used a stacking window manager which allowed overlapping windows.[4] While it is unclear if Microsoft Windows contains designs copied from Apple's Mac OS, it is clear that neither was the first to produce a GUI using stacking windows. In the early 1980s, the Xerox Star, successor to the Alto, used tiling for most main application windows, and used overlapping only for dialogue boxes, removing most of the need for stacking.[5]
GEM 1.1 was a window manager which supported the desktop metaphor, and used stacking, allowing all windows to overlap. It was released in the early 1980s.[6] GEM is famous for having been included as the main GUI used on the Atari ST, which ran Atari TOS, and was also a popular GUI for MS-DOS prior to the widespread use of Microsoft Windows. As a result of a lawsuit by Apple, GEM was forced to remove the stacking capabilities, making it a tiling window manager.[7]
Mac OS was one of the earliest commercially successful examples of a GUI which used a sort of stacking window management via QuickDraw. Currently Mac OS X uses a somewhat more advanced window manager which has supported compositing since Mac OS X 10.0, and was updated in Mac OS X 10.2 to support hardware accelerated compositing via the Quartz Compositor.[8]
During the mid 1980s, Amiga OS contained an early example of a compositing window manager called "Intuition" (one of the low-level libraries of AmigaOS, which was present in Amiga system ROMs), capable of recognizing which windows or portions of them were covered, and which windows were in the foreground and fully visible, so it could draw only the desired parts of the screen that required to be refreshed. Additionally, Intuition supported compositing. Applications could first request a region of memory outside the current display region for use as bitmap. The Amiga windowing system would then use a series of bit blits using the system's hardware blitter to build a composite of these applications' bitmaps, along with buttons and sliders, in display memory, without requiring these applications to redraw any of their bitmaps.
Intuition also anticipated the choices of the user by recognizing the position of the pointer floating over other elements of the screen (title bars of windows, their close and resizing gadgets, whole icons), and thus it was capable of granting nearly a zero-wait state experience to the use of the Workbench window manager.
Noteworthy to mention is the fact that Workbench was the only window manager that eventually inspired an entire family of descendant and successors: Ambient in MorphOS, Zune/Wanderer in AROS, Workbench NG (New Generation in AmigaOS 4.0 and 4.1. Workbench 4.1 was enhanced by 2D vector interface powered by Cairo libraries, and presenting a modern Porter-Duff 3D based Compositing Engine.
In 1988, Presentation Manager became the default shell in OS/2, which, in it's first version, only used a command line interface (CLI). OS/2 was designed by IBM and Microsoft to be the successor of DOS and the Windows for DOS, but after the success of the Windows 3.10, Microsoft abandoned the project in favor of Windows. After that, the Microsoft project for a future OS/2 version 3 became Windows NT, and IBM made a complete redesign of the shell of OS/2, substituting the Presentation Manager of OS/2 1.x for the object-oriented Workplace Shell that made it's debut in the OS/2 2.0.[9]
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||||||